Version3000Date20221127191108 This migration should be run before testing these changes
Navigate to /server and run php occ migrations:migrate 3000Date20221127191108

I am not really sure here. First I agree that concurrent editing is not on the schedule and out of scope.

But I rather think we should change the editing a bit:

1. check user has edit permissions
2. acquire edit lock on server (needed to prevent collisions)
3. submit changes
4. release lock

This would required two columns I think (locked_by and locked_since).
The locked_by defines the current user holding the lock (null if not locked) and locked_since is used to release the lock after a defined IDLE time to not deadlock editing (e.g. 5 minutes without activity).

What do you think? Also cc @Chartman123

Yes, some kind of locking would be necessary. I'd just use locked_until instead of locked_since but in the end it's the same. Instead of using a timeout for locking we could also implement a method to manually unlock a form (perhaps only for the owner?)

Instead of using a timeout for locking we could also implement a method to manually unlock a form (perhaps only for the owner?)

I think we need the timeout, but could do both. Otherwise we might end up in a lot of situations where the owner is needed to unlock.